Shareware Grab Bag

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Grab Bag / Shareware Grab Bag.iso / 081 / confmail.arc / CONFMAIL.DOC next >

Wrap

Text File | 1987-12-12 | 86.9 KB | 2,707 lines

The Conference Mail System By Bob Hartman Sysop of FidoNet(tm) node 132/101 (C) Copyright 1986,87, Spark Software, Inc. 427-3 Amherst Street CS 2032, Suite 232 Nashua, N.H. 03061 ALL RIGHTS RESERVED. Conference Mail System Revision 3.3 December 12, 1987 WHAT IS THE CONFERENCE MAIL SYSTEM? Conference Mail is a technique to permit several nodes on a network to share a message base, similar in concept to the conferences available on many of the computer services, but it is most closely related to the Usenet system consisting of more than 8,000 systems world wide. All systems sharing a given conference see any messages entered into the conference by any of the participating systems. This can be implemented in such a way as to be totally transparent to the users of a particular node. In fact, they may not even be aware of the network being used to move their messages about from node to node! Unfortunately, this has its disadvantages also - most users who are not educated about Conference Mail do not realize the messages transmitted cost MANY sysops (system operators) money, not just the local sysop. This is an important consideration in Conference Mail and should not be taken lightly. In a conference with 100 systems as participants the cost per message can get quite high. The Conference Mail System is designed to operate in conjunction with a FidoNet compatible mail server. The currently supported mail servers are Fido(tm), SEAdog(tm), Opus, and Dutchie. Since the mail server is a prerequisite to using the Conference Mail System, it will be assumed you already have your mail server operating correctly on your system, and you are connected into FidoNet or a compatible network. Page 2 Conference Mail System Revision 3.3 December 12, 1987 HISTORY OF THE CONFERENCE MAIL SYSTEM In late 1985, Jeff Rush, a Fido sysop in Dallas, wanted a convenient means of sharing ideas with the other Dallas sysops. He created a system of programs he called Echomail, and the Dallas sysops' Conference was born. Within a short time sysops in other areas began hearing of this marvelous new gadget and Echomail took on a life of its own. Today, a scant year and a half later, the FidoNet public network boasts a myriad of conferences varying in size from the dozen-or- so participants in the FidoNet Technical Standards Committee Conference to the Sysops' Conference with several hundred participants. It is not uncommon for a node to carry 30 or more conferences and share those conferences with 10 or more nodes. Unfortunately, this incredible growth pointed out limits in the original Echomail programs. In particular, the processing was slow, a few 'bugs' surfaced, and more features were needed to make a sysop's life just a bit easier. In November of 1986 I (Bob Hartman) began work on the Conference Mail System, a faster, more powerful system compatible with Echomail. This system started out as a series of programs called FastToss, FastKDup and FastScan. The system was relatively bug free, and provided significantly greater speed than the original Echomail utilities. It also added functions designed to make Echomail more attractive to the average sysop. The current version of Conference Mail has more features, and is faster than what was known as the FastEcho series of programs. This newest program is what you have received with along this documentation.. Page 3 Conference Mail System Revision 3.3 December 12, 1987 HOW IT WORKS The Conference Mail System is functionally compatible with the original Echomail utilities. In general, the process is: 1. A message is entered into a designated area on a FidoNet compatible system. 2. This message is "Exported" along with some control information to each system "linked" to the conference through the originating system. 3. Each of the receiving systems "Import" the message into the proper Conference Mail area. 4. The receiving systems then "Export" these messages, along with additional control information, to each of their conference links. 5. Return to step 3. As you can see, the method is quite simple - in general. Of course, following the steps literally would mean messages would never stop being Exported and transmitted to other systems. This obviously would not be desired or the network would quickly become overburdened. The information contained in the 'control information' section is used to prevent transmitting the same message more than once to a single system. Page 4 Conference Mail System Revision 3.3 December 12, 1987 CONFERENCE MAIL MESSAGE CONTROL INFORMATION There are five pieces of control information associated with a Conference Mail message. Some are optional, some are not. Normally this information is never entered by the person creating the message. The following control fields determine how Conference Mail is handled: 1. Area line This is the first line of a conference mail message. Its actual appearance is: AREA:CONFERENCE Where CONFERENCE is the name of the conference. This line is added when a conference is being "Exported" to another system. It is based upon information found in the AREAS.BBS (configuration) File for the designated message area. This field is REQUIRED by the receiving system to "Import" a message into the correct Conference Mail area. 2. Tear Line This line is near the end of a message and consists of three dashes (---) followed by an optional program specifier. This is used to show the first program used to add Echomail compatible control information to the message. The tear line generated by Conference Mail looks like: --- ConfMail v3.3 This field is optional for most Echomail compatible processors, and is added by the Conference Mail System to ensure complete compatibility. Some systems will place this line in the message when it is first created, but it is normally added when the message is first "exported." 3. Origin line This line appears near the bottom of a message and gives a small amount of information about the system where it originated. It looks like: * Origin: The Conference Mail BBS (1:132/101) The " * Origin: " part of the line is a constant field. This is followed by the name of the system as taken from the AREAS.BBS file or a file named ORIGIN located in the DOS directory of the designated message area. The complete network address (1:132/101 in this case) is added by the program inserting the line. This field is generated at the same time as the tear line, and therefore may either be generated at the time of creation or during the first "export" processing. Although the Origin line is not required by all Echomail processors, it is added by the Conference Mail System to ensure complete compatibility. Page 5 Conference Mail System Revision 3.3 December 12, 1987 4. Seen-by Lines There can be many seen-by lines at the end of Conference Mail messages, and they are the real "meat" of the control information. They are used to determine the systems to receive the exported messages. The format of the line is: SEEN-BY: 132/101 113 136/601 1014/1 The net/node numbers correspond to the net/node numbers of the systems having already received the message. In this way a message is never sent to a system twice. In a conference with many participants the number of seen-by lines can be very large. This line is added if it is not already a part of the message, or added to if it already exists, each time a message is exported to other systems. This is a REQUIRED field, and Conference Mail will not function correctly if this field is not put in place by other Echomail compatible programs. 5. PATH Lines These are the last lines in a Conference Mail message and are a new addition, and therefore is not supported by all Echomail processors. It appears as follows: ^aPATH: 132/101 1014/1 Where the ^a stands for Control-A (ASCII character 1) and the net/nodes listed correspond to those systems having processed the message before it reached the current system. This is not the same as the seen-by lines, because those lines list all systems the message has been sent to, while the path line contains all systems having actually processed the message. This is not a required field, and few echomail processors currently support it, however it can be used safely with any other system, since the line(s) will be ignored. For a discussion on how the path line can be helpful, see the "Advanced Features" section of this manual. Page 6 Conference Mail System Revision 3.3 December 12, 1987 SETTING UP THE CONFERENCE MAIL SYSTEM To set up the Conference Mail System, the following steps must be followed: 1. Have a working FidoNet compatible system using the message format described by the FidoNet Technical Standards Committee (FTSC) in the document FSC001. This basically means TBBS systems cannot use the Conference Mail System since they do not have a message base of the appropriate format. Systems known to work with the Conference Mail System are listed in the "What is Conference Mail?" section of this manual. 2. Determine the conferences you would like to start, and the conferences you would like to receive. A good place to start is by looking for a file called ECHOLST.ARC on your local bulletin board already running an Echomail compatible system. This list contains information on tying into over 100 known conferences are already popular throughout FidoNet. 3. Set up a directory for messages for each of the separate conferences. Yes, you read correctly - one directory for each conference. If you do not create individual directories, then you will run into a problem known as "cross-linking" a conference. This means the information from one conference will end up intermingled with another. Although this is sometimes desirable, generally it causes severe backlash at the person responsible. For example, imagine if the two areas accidentally cross-linked were the BLACK_MAGIC and BIBLE areas. Needless to say there would be an uproar in the conference getting material originally destined for the other conference. Unfortunately, this happens all too often, and even the most experienced Conference Mail wizards will make this mistake. Refer to the documentation for your FidoNet compatible system for how to make this directory accessible to the system. 4. Set up the AREAS.BBS configuration file for your system and the conferences you wish to receive (see the section entitled "Configuration (AREAS.BBS) file). This file must be in the correct format, and should be thoroughly tested on a small scale before linking to any large conferences. 5. Alter your batch files to make the appropriate calls to the Conference Mail system for importing, exporting and maintaining the message bases. Samples batch file sections are given in the section entitled "Batch File Examples". Page 7 Conference Mail System Revision 3.3 December 12, 1987 6. Set up conference links with other systems for the conferences you are interested in. To do this, simply send a netmail message to the other system requesting to tie into the conference in question. If the sysop does not carry the conference they can usually point you in the right direction. Remember when setting up links, local calls are preferred since Conference Mail can generate large phone bills if taken to extremes. Also be careful of conference "topology" (see the section entitled "Conference Topology" for more details). Also determine with the other sysop if "ARCmail" is to be used or not (ARCmail is discussed in the section entitled "Methods of Sending Conference Mail"). If all of these procedures are followed, then the result should be a fully operational Conference Mail System. Page 8 Conference Mail System Revision 3.3 December 12, 1987 CONFIGURATION (AREAS.BBS) FILE The Configuration File for the Conference Mail System is usually called AREAS.BBS. It may be called any name, but AREAS.BBS is used for historical reasons. The file has 4 parts: 1. Comment lines - these lines may appear anywhere in the file. They are blank lines, or start with a semi-colon (;). Historically there is one other special type of comment line starting with a dash (-). The Conference Mail System uses some of the dash lines as "special command" lines (see number 3 below). 2. Board name ! Sysop name - this line is the first line of the file other than comment lines. This line is used by the Conference Mail System when it generates an Origin line (see section entitled "How it Works"), and also the name to be substituted for Sysop when it is found in the FROM field of a message. The format of the line is free format with the board name and sysop name separated by an exclamation point (!). The zone:net/node will be appended to this information, so it should never appear in the file itself. For example: The Conference Mail BBS ! Bob Hartman might expand to: * Origin: The Conference Mail BBS (1:132/101.1) 3. Special Commands - these lines begin with a dash (-) and are followed by a special keyword. The supported keywords (discussed in the "Advanced Features" section) are: All versions: ZONEGATE PASSWORD "Point" versions: POINTNET BOSSNODE 4. Conference lines - All other lines in the file fit into the category of Conference lines. These lines have a very special format as follows: Directory Area Nodes Each line has the same format, although each line may use the following format pieces differently: Directory - this may be either a path name (easiest and recommended method) or it may be a Fido/Opus area number. Area - This is the label associated with the Conference. It is important to have this spelled correctly (upper/lower case does not matter) since incorrectly spelled area names will not be recognized. Page 9 Conference Mail System Revision 3.3 December 12, 1987 Nodes - These are the nodes sharing the conference. The format is a list of net/node numbers for each node. If the net number is the same for two consecutive nodes, then the net number and slash (/) may be deleted for the second number. For example, both of the following are equivalent (the first node number must have an associated net number): 132/101 132/107 132/555 136/601 132/101 107 555 136/601 The entire list of nodes is optional for a conference - it is often desirable to have an area called GENERAL and another called PRIVATE with no links listed in order to get general or private mail from other boards running compatible software (this is considered standard practice, although as some users have said "You may go a lifetime and never see anyone use this feature on your system, but the capability is there"). On a system running "secure" Conference Mail (see section entitled "Advanced Features"), this is not recommended. Sample Configuration (AREAS.BBS) File: ; The first line that is not a comment line is the ; Board Name ! Sysop Name line. This MUST appear or ; the Conference Mail System will not function correctly The Conference Mail BBS ! Bob Hartman ; The next section of lines is my "special command" ; section. It gives examples of the use of three ; "special" commands. This is actually the ; setup for a possible "point server" node. For a ; "point" itself, the POINTNET line would be changed ; to a BOSSNODE line as in "-BOSSNODE=132/101". Note ; the dash (-) is in column 1 (this is important) ; and there are no spaces until after the number ; following the equal sign (=). -POINTNET=1014 -ZONEGATE=3/1 1/3 105/30 -PASSWORD=1014/1 ConfMail ; Now come all of the Conference Lines: ; Directory Area Node 1 Node 2 Node 3 Node 4 C:\MSG\PRIVATE PRIVATE C:\MSG\GENERAL GENERAL C:\MSG\SYSOP SYSOP 132/101 136/601 107/312 1014/1 C:\MSG\TECH TECH 132/101 136/601 107/312 1014/1 C:\MSG\POINT POINT 1014/1 C:\MSG\NESYSOP NESYSOP 132/101 1014/1 ; The above lines are in columns simply to be pleasing ; to the eye. It is not necessary, but it does make ; changing the lists much easier. The column headings ; are also given for clarity and are not required. Page 10 Conference Mail System Revision 3.3 December 12, 1987 METHODS OF SENDING CONFERENCE MAIL To this point the issue of how Conference Mail is actually sent has been glossed over entirely. The phrase has been, "the message is exported to another system." What exactly does this mean? Well, for starters lets show what is called the "basic" setup: In this setup exported mail is placed into the FidoNet mail area. Each message exported from a Conference Mail area has one message generated for each receiving system. This mail is then sent the same as any other network mail. When Echomail was first created this was the only way mail could be sent. The "basic" method has some disadvantages. First, since Echomail has grown so large it is not uncommon to get 200 new messages per day imported into various message bases. It is also not uncommon for a system to be exporting messages to 4 or 5 other systems. Simple arithmetic shows 800-1000 messages per day would be sent in normal netmail! This puts a tremendous strain on any netmail system, not to mention transmission time and the resultant phone charges. When this limitation of Echomail was first noticed a lot of people started scratching their heads wondering what to do. If a solution could not be found it appeared Echomail would certainly overrun the capabilities of FidoNet. Thom Henderson (from System Enhancement Associates) came up with the original ARCmail program. Having previously written the ARC file archiving and compression program, he knew the savings achievable by having all of the netmail messages placed in .ARC format for transmission. As a byproduct, the messages no longer appeared in the netmail area, but were included in a file attached to a message (see your FidoNet mailer manual for file attaches). In this way the tremendous number of messages generated, and the phone bill problems were both solved. Unfortunately, ARCmail required the messages to first be placed into the netmail area before it could be run. In effect, it caused the messages to be scanned once when they were exported, once during the ARCmail phase, once when ARCmail was run at the other end to get the messages out of .ARC format, and once when those messages were later imported into a message base on the receiving system. The Conference Mail System solves this problem by eliminating the ARCmail program. Conference Mail builds the ARCmail files during Export, and unpacks them during Import. This way messages are exported directly to ARCmail style file attaches, and imported directly from ARCmail style file attaches. The scanning phases between importing and exporting messages are totally removed and processing time is proportionally reduced. This is now the most common method for sending Conference Mail between systems. The overhead involved in doing it during the importing and exporting phases is much less than what is involved if ARCmailing is not utilized. This was a primary consideration in the design and implementation of the Conference Mail System, and as a result the entire system is optimized for this type of use. Please refer to the Import and Export functions for specifics on how to use the ARCmailing feature. Page 11 Conference Mail System Revision 3.3 December 12, 1987 CONFERENCE TOPOLOGY The way in which systems link together for a particular conference is called the "conference topology." It is important to know this structure for two reasons: 1) It is important to have a topology which is efficient in the transfer of the Conference Mail messages, and 2) It is important to have a topology which will not cause systems to see the same messages more than once. Efficiency can be measured in a number of ways; least time involved for all systems to receive a message, least cost for all systems to receive a message, and fewest phone calls required for all systems to receive a message are all valid indicators of efficiency. Users of Echomail compatible systems have determined (through trial and error) the best measure of efficiency is a combination of all three of the measurements given above. Balancing the equation is not trivial, but some guidelines can be given: 1. Never have two systems attempting to send Conference mail to each other at the same time. This results in "collisions" that will cause both systems to fail. To avoid this, one system should be responsible for polling while the other system is holding mail. This arrangement can alternate based upon various criteria, but both systems should never be attempting to call each other at the same time. 2. Have nodes form "stars" for distribution of Conference Mail. This arrangement has several nodes all receiving their Conference Mail from the same system. In general the systems on the "outside" of the star poll the system on the "inside". The system on the "inside" in turn polls other systems to receive the Conference Mail that is being passed on to the "outside" systems. 3. Utilize fully connected polygons with a few vertices. Nodes can be connected in a triangle (A sends to B and C, B sends to A and C, C sends to A and B) or a fully connected square (all corners of the square send to all of the other corners). This method is useful for getting Conference Mail messages to each node as quickly as possible. Page 12 Conference Mail System Revision 3.3 December 12, 1987 All of these efficiency guidelines have to be tempered with the guidelines dealing with keeping duplicate messages from being exported. Duplicates will occur in any topology that forms a closed polygon that is not fully connected. Take for example the following configuration: A ----- B | | | | C ----- D This square is a closed polygon that is not fully connected. It is capable of generating duplicates as follows: 1. A message is entered on node A. 2. Node A exports the message to node B and node C placing the seen-by for A, B, and C in the message as it does so. 3. Node B sees that node D is not listed in the seen-by and exports the message to node D. 4. Node C sees that node D is not listed in the seen-by and exports the message to node D. At this point node D has received the same message twice - a duplicate was generated. Normally a "dup-ring" will not be as simple as a square. Generally it will be caused by a system on one end of a long chain accidentally connecting to a system on the other end of the chain. This causes the two ends of the chain to become connected, forming a polygon. In FidoNet this problem is reduced somewhat by having "Regional Echomail Coordinators" (RECS) that try to keep track of Echomail connections within their regions of the world. A further rule which is followed is that only the RECS are allowed to make inter-regional connections for the larger conferences. In return, the RECS have established a very efficient topology which gets messages from coast to coast, and onto over 200 systems in less than 24 hours. If no one were willing to follow the rules, then this system would collapse, but due to the excellent efficiency it has remained intact for over a year. Page 13 Conference Mail System Revision 3.3 December 12, 1987 ADVANCED FEATURES Special AREAS.BBS Commands (all versions of Conference Mail) PASSWORD The format for this line is: -PASSWORD=net/node password where 'net/node' is the net/node number of the system using this password, and 'password' is up to 8 characters of a password. This option is currently only supported by the Conference Mail System. The method used for this feature has been approved by the FidoNet Technical Standards Committee (FTSC), and should start appearing in other Echomail processors in the future. Up to 100 systems can be given passwords by having a separate -PASSWORD= line for each one. If Conference Mail is received in ARCmail format from a system listed on a -PASSWORD= line, the ARCmail packet will be checked for the proper password, and if the password is missing, or incorrect the packet will be renamed and a message generated to alert the sysop. ARCmail created for a node listed on a -PASSWORD= line will be generated with the password in place, so the receiving system should also have the same password in place in their AREAS.BBS file. This is part of the security discussed more fully in the section entitled "Creating a Secure Environment." ZONEGATE The format for this line is: -ZONEGATE=a/b c/d e/f ... where 'a/b' is the net/node number of the system that is the "zonegate" and 'c/d e/f ...' are the net/node numbers to be listed in the seen-by lines of messages exported to the "zonegate." This option is primarily used to keep transmission costs down by deleting seen-bys for systems that are not in the same "zone". If a message goes through a "zonegate" it can never return except through the same "zonegate", hence all seen-bys for the original zone can safely be removed. This option allows this, as well as specifying a extra seen-bys to be listed in case the PASSTHRU option is also being used (see the section entitled "Using the Passthru Option"). Page 14 Conference Mail System Revision 3.3 December 12, 1987 Special AREAS.BBS Commands ("Point" versions of Conference Mail) POINTNET This format for this line is: -POINTNET=net Where 'net' corresponds to the net number of the private net which is used to support "points." This option should ONLY be used on a system supporting points, and never on an actual point. This option strips all occurances of the private net number from appearing in the seen-by lines of messages exported to other systems. This is necessary since many nodes might have the same private network number for the points that they service, and seen-by lines generated on one system might cause points on another system to not receive the messages. BOSSNODE The format for this line is: -BOSSNODE=net/node where 'net/node' is the net/node number of the system which acts as a point server. This option should ONLY be used on a system which is a point. It causes the Origin line to contain a fully qualified network address as: zone:net/node.point rather than the usual: zone:net/node The fully qualified address is generated as follows: zone - from the zone in the CONFIG.DOG file, otherwise it defaults to zone 1. net - from the net listed on the -BOSSNODE= line. node - from the node listed on the -BOSSNODE= line. point - from the node listed in the primary address found in the system information file (see section entitled "Required Files"). For example, if the primary address is 1:1014/1, and the line -BOSSNODE=132/101 appeared in the AREAS.BBS file, then the fully qualified address would be 1:132/101.1 Page 15 Conference Mail System Revision 3.3 December 12, 1987 Creating a "Secure" Environment: For the purposes of this section, a "secure" system will be defined as: one accepting echomail only from sources which can be verified. In other words, a "hacker" cannot enter echomail messages without getting caught. In order to create a secure system, the ways in which a "hacker" can enter echomail messages without being detected have to be identified and countered: 1. The first (and most commonly used method) is to create a regular Fidonet mail message to a node running echomail. This message is created with the various echomail control information lines in place. When the receiving system gets the message it imports it into a message area based on the AREA: line, and the "hacker" has successfully entered an echomail message. The Conference Mail System stops this problem with the -M option for the Import function. A regular netmail message will never be imported. 2. The second method is by sending ARCmail file attaches. Again, the receiving system will unpack the ARCmail and import it into the message areas based on the AREA: lines. This is addressed by the -S option for the Import function. If the system sending the message does not appear in the AREAS.BBS file for the conference, the message is redirected to the netmail area for the sysop. 3. The third method is to send ARCmail file attaches with a net/node number that is known to be in the AREAS.BBS file. This would not get caught by the checking done to stop number 2, and therefore is the most difficult to detect. The Conference Mail System addresses this by allowing ARCmail packets to have an associated password. The sysops of the two systems exchanging mail decide upon a password and if it is not present in the ARCmail, then the secure system will rename the packet and alert the sysop to what transpired. If the combination of the Import -S and -M options as well as passwording is used, the system is secure. Because "hackers" are always thinking up new ways to break into systems, Conference Mail goes one step further - identifying the perpetrator. When a message is being exported, it is analyzed, and if it has traits which tend to make it look like a locally originated message, yet it was not entered locally, the phrase ' Of net/node' is appended to the "From:" field of the message. For example, if a message is being exported that falls into this category, and it is from "Scott Tissue", the exported messages will be appear to be from "Scott Tissue Of net/node" where net/node is the net/node number of the system which sent the message. Having the ability to impersonate anyone else when sending an echomail message has been abused within FidoNet. This abuse led to the security features mentioned above being made integral to the design of the Conference Mail System. Do not underestimate what might happen to you! When possible, implement security. Page 16 Conference Mail System Revision 3.3 December 12, 1987 Why a PATH line? As was previously mentioned, the PATH line is a new concept in Echomail. It stores the net/node numbers of each system having actually processed a message. This information is useful in correcting the biggest problem encountered by nodes running an Echomail compatible system - the problem of finding the cause of duplicate messages. How does the PATH line help solve this problem? Take the following path line as an example: ^aPATH: 107/6 107/312 132/101 This shows the message was processed by system 107/6 and transferred to system 107/312. It further shows system 107/312 transferred the message to 132/101, and 132/101 processed it again. Now take the following path line as the example: ^aPATH: 107/6 107/312 107/528 107/312 132/101 This shows the message having been processed by node 107/312 on more than one occasion. Based upon the earlier description of the 'information control' fields in Echomail messages, this clearly is an error in processing (see the section entitled "How it Works"). This further shows node 107/528 as the node which apparently processed the message incorrectly. In this case the path line can be used to quickly locate the source of duplicate messages. In a conference with many participants it becomes almost impossible to determine the exact topology used. In these cases the use of the path line can help a coordinator of the conference track any possible breakdowns in the overall topology, while not substantially increasing the amount of information transmitted. Having this small amount of information added to the end of each message pays for itself very quickly when it can be used to help detect a topology problem causing duplicate messages to be transmitted to each system. Page 17 Conference Mail System Revision 3.3 December 12, 1987 Special Situations: The Conference Mail System can handle a number of special situations. Points and security are two situations already mentioned. Other situations are "passthru", "bad messages", "routed conferences", "splitting" a conference, and "merging" a conference. Passthru: The ZONEGATE special AREAS.BBS command has already been mentioned, but there is one more special feature of Conference Mail that can be utilized by zonegates. This is the ability to "passthru" echomail areas without having to retain them. This feature is triggered by a special area name of "PASSTHRU" listed in the AREAS.BBS file, along with systems to be linked with the area. The PASSTHRU area works as follows: 1. All messages that have an unrecognized AREA: line are imported into the PASSTHRU area. The original AREA: line is left intact (normally Import will remove the AREA: line when placing a message in a regular Conference Mail message base). 2. Export processes the PASSTHRU area like any other area, with one exception: it does not add an AREA: line to the messages since the line is already there. 3. Export does not update the seen-by lines in the messages that are retained in the PASSTHRU area. These three items allow messages to simply pass thru a system that is functioning as a zone gateway. The systems on each side of the zone gateway can add areas, and never have to inform the zone gateway. This function is designed ONLY for zone gateways. Other uses should be carefully thought out before implementation. Page 18 Conference Mail System Revision 3.3 December 12, 1987 Bad Messages: Another special feature of the Conference Mail System is the ability to have "bad messages" placed in a special area. This allows the sysop to analyze the messages to see what the problems are, and then to fix them. This feature is triggered by a special area name of "BAD_MSGS" listed in the AREAS.BBS file. The BAD_MSGS directory will contain any messages that could not be tossed for some reason (other than a bad password). Possibilities are: 1. An uknown area name. 2. The message is a duplicate of one of the last 1000 messages in the area. 3. The message is from a node that is not listed in the AREAS.BBS file, and secure operation was enabled. Routed Conferences: It is not uncommon for conference messages to be routed rather than being sent directly to the destination. This practice is frowned upon unless the system being used for the routing confirms that it is alright. A situation like this can occur if a conference distributor has a "free" phone line and can send to other nodes at a lower cost than sending the conferences directly. The ROUTETHRU area name is a special name reserved for this purpose. If a conference message is received, and it is not addressed to the current node, it is then placed in the directory associated with the ROUTETHRU area name. When this area is exported, the net/node number of the receiving system is taken from the message header, rather than the AREAS.BBS file, or the SEEN-BY lines. This is generally a useful option for network hosts to use. Merging a Conference: In the section entitled "How Conference Mail Works", mention was made to "cross-linking" areas, and how undesirable it was. This section deals with the special case when it is not undesirable. One such situation arises when a conference is being disbanded in favor of another conference on the same topic. In this case it is desirable to have the two conferences merged together for a period of time. The Conference Mail System can handle this situation by listing the same message directory with two or more different area names in the AREAS.BBS file. For example, to merge together the TURBO_PASCAL and PASCAL conferences, the following lines would appear in the AREAS.BBS file used by Import: C:\MSG\PASCAL TURBO_PASCAL 107/312 136/601 C:\MSG\PASCAL PASCAL 114/15 161/1 Extreme care should be used when deliberately cross-linking a conference. Page 19 Conference Mail System Revision 3.3 December 12, 1987 Splitting a Conference: Another special case arises when two systems want to call the same conference by different names. The Conference Mail System can handle this situation the same way it handles splitting conference. The example given above could also be used by the AREAS.BBS file used for Export. It would split the conference into two conferences called TURBO_PASCAL received by 107/312 and 136/601, and PASCAL received by 114/15 and 161/1. Page 20 Conference Mail System Revision 3.3 December 12, 1987 CONFERENCE MAIL COMMAND SUMMARY In General: The Conference Mail System is driven by a single program contained in the executable file CONFMAIL.EXE. All of the tasks for the Conference Mail System are actually performed by many sub-functions. In the section entitled "Conference Mail Sub- Function Summary", all sub-function names should be preceded by the program name. For example: Import -N should be given on the command line as: ConfMail Import -N There is one special case where this is not true: The ConfMail program is capable of taking its input parameters from a "command file." The sub-function calls in this command file are NOT preceded by the name 'ConfMail'. To utilize this ability it is necessary to call the ConfMail program with a second argument of 'FILE' and the third argument being the filename to use as a command file. Additional arguments are numbered sequentially, and can be used as %1 thru %9 in the command file. For example: ConfMail FILE ConfMail.CMD 10 ConfMail.Dat Where ConfMail.CMD may contain any valid ConfMail sub-function calls such as: Import -N -F %2 -A PKXARC Maint -F %2 Export -A PKXARC Renum -O -D %1 C:\MSG\SYSOP Renum -O C:\MSG\TECH Any number of ConfMail Sub-function calls may be executed. The command file is only aborted if there is an abnormal error in processing for any of the functions. Page 21 Conference Mail System Revision 3.3 December 12, 1987 Required Files: System Information File: The Conference Mail System requires a system information file to be present. This file is called either MAIL.SYS in the current directory (Fido systems), or a file called CONFIG.DOG in the directory named by the SEADOG environment variable or the current directory. In the case of MAIL.SYS, Fido creates and maintains this file for you (refer to the Fido documentation). The CONFIG.DOG file should contain the following: NODE zone:net/node The zone:net/node of the system MAIL mailpath mailpath corresponds to the directory containing the FidoNet mail area. FILES filepath filepath corresponds to the directory used to store incoming FidoNet files. AKA net/node This statement is not required, but if present gives alternate net/node numbers for the system, and will include, by default, the first AKA net/node address in the seen-by lines of exported messages. Any other statements in the file area ignored. If your system does not have a MAIL.SYS file, then it will be necessary to create a CONFIG.DOG file using the statements given above. The Conference Mail System will not function without one or the other. The CONFIG.DOG file takes precedence if both exist. Origin Line Files: When the Conference Mail System exports a message that does not have an Origin line, one is appended. This line is normally formed from the 'board name' section of the AREAS.BBS configuration file being used. This default can be overridden by having a file named 'ORIGIN' in the DOS directory containing the messages for a conference. When a message in the conference needs to have an Origin line appended it will then be taken from the first line of the ORIGIN file. Page 22 Conference Mail System Revision 3.3 December 12, 1987 Message Identification Database: This is a file named CONFDUPS.DAT that is present in each conference mail message directory. IT SHOULD NEVER BE DELETED. This file contains identification information for the last 1000 messages to appear in the conference, and it is used by the Import sub-function to delete duplicate messages before they appear in the conference. It is maintained by the Import sub-function, and should never be altered or deleted. It will take up approximately 10K bytes (the size of 5 average messages) in each conference directory. Page 23 Conference Mail System Revision 3.3 December 12, 1987 CONFERENCE MAIL SUB-FUNCTION SUMMARY IMPORT: Function: Receives Conference Mail messages and places them into the proper message base (if they are not duplicates of earlier messages). Format: Import [afile] [-K] [-N or -O] [-M] [-S] [-F file] [-D num_dups] [-A [ARC_cmd]] Options: afile This is the name of the AREAS.BBS file to use for this run. -K Delete NULL messages rather than imported them. -N or -O Specifies imported messages should have their date formats changed to the new Opus 1.0 format (-N option), or the older Fido format (-O option). The default is to do no conversion. -M Messages will NOT be imported from the network mail directory. This option is useful for a "secure" environment (see the section entitled "Advanced Features"). The default is to Import messages from the network mail area. -S Import will operate in "secure" mode. This means messages will not be imported to Conference Mail message bases unless the sending node is listed as a recipient of the conference; the messages will be placed into the Fidonet mail area instead. This option is useful for a "secure" environment (see the section entitled "Advanced Features"). -F file Each Conference Mail area having a message imported to it will have the area name listed in the file named 'file'. This is for correlating the workings of Import and Maint. Page 24 Conference Mail System Revision 3.3 December 12, 1987 -D num_dups Allow for killing duplicates based on the last 'num_dups' messages received in each area. The default for num_dups is 1000, and should only be decreased. If the default is increased, there is a very good chance that not enough memory will be present in the default 64K data space, and the program will exit with a warning. -A [ARC_cmd] Import will attempt to extract ARCmail files. The ARC_cmd parameter will be used as the command to unARC, and if not given will default to 'ARC X'. This option MUST be last on the command line, and everything following the -A is taken as the unARC command. Errorlevels returned: 0 - No messages imported 1 - Messages were imported 2 - Severe error in processing Examples: To import messages without date conversion, and to extract ARCmail using the ARC command: Import -A ARC X To import messages in Opus 1.0 format from the netmail area only: Import -N To import messages in Opus 1.0 format and also extract ARCmail using the PKXARC program: Import -N -A PKXARC To use the file AREAS1.BBS for Importing, create a list of areas having messages Imported into them, and to extract ARCmail (using the default of 'ARC X'): Import AREAS1.BBS -F Conf.Out -A Maximum security operation of Import using ARCE to extract the ARCmail files: Import -M -S -A ARCE Page 25 Conference Mail System Revision 3.3 December 12, 1987 EXPORT: Function: Prepares messages for transmission to other systems sharing the Conference. Format: Export [afile] [-0/1] [-M #] [-K] [-S #] [-C] [-H] [-T] [-I] [-Q] [-R] [-G] [-NF/P] [-O dir] [-P dir] [-D dir] [-F file] [-A ARC_cmd] Options: afile This is the name of the AREAS.BBS file to use for this run. -0 or -1 Use either the primary (0) or alternate (1) set of high water marks. This can be used in instances where two AREAS.BBS files are useful. One such instance occurs when some nodes receiving a conference wish to receive ARCmail, and other nodes do not want ARCmail. -M # Export messages until '#' of messages have been exported. The Conference Mail System will completely export a message before stopping, so this number may be exceeded by a few messages. -K Use the International FidoNet Association (IFNA) endorsed "kludge" of hiding the AREA and SEEN-BY lines behind a Control-A character. This option should not be used by systems which must communicate with older echomail compatible systems. -S # Add '#' AKA addresses to the seen-by lines. This number does not include the primary address which is always included in the seen-by lines. The default is to have 1 AKA included. -C Set the CRASH bit on messages and ARCmail file attaches. -H Set the HOLD bit on messages and ARCmail file attaches Page 26 Conference Mail System Revision 3.3 December 12, 1987 -T Strip the seen-by list down to a 'tiny' subset. This list consists of the current system, plus any conference links the system maintains. For example: System 132/101 maintains links with 107/312 and 136/601 in the SYSOP conference. A message is being exported from that conference, and the current seen-by list is: SEEN-BY: 107/6 107/312 107/528 120/38 133/1 The new seen-by list would be: SEEN-BY: 107/312 132/101 136/601 This option should be used with EXTREME care. It can cause a topology which had not been generating duplicate messages to suddenly start generating them. See the section entitled "Troubleshooting" for more information. -I Use internal ARCmailing on Opus systems. -Q Operate in "quiet" mode. -R Send private conference replies via netmail. This option will cause messages that are replies to previous messages, and also marked private to be sent via netmail, rather than being exported as a normal Conference Mail message. This is useful for a conference coordinator, as well as individuals wishing to reply to a message but not have all of the conference participants see the reply. -G Disable the generation of the PATH line in exported messages. Currently there is no need to ever use this option, however, it is available in case there are compatibility problems in the future. -NF Do not forward messages that did not originate on this system. This option should only be used by systems on the end of a topology chain (see the section entitled "Conference Topology" for more information). Page 27 Conference Mail System Revision 3.3 December 12, 1987 -NP Do not forward private messages via echomail. If a private message is encountered, and it is not a reply it will not be sent. If it is a reply and the -R switch is not used, then it also will not be sent. If the -R switch is in use, and the message is marked private, then the logic for the -R switch will be utilized. -O dir For use by Opus 1.0 systems. Place exported messages in .OUT files in the DOS directory 'dir'. These messages can later be processed by oMMM. This option MUST be used by systems using Opus 1.0 for outbound FidoNet mail. -P dir Temporary packets created by the ARCmailing process will be placed in the DOS directory 'dir'. If 'dir' is on a RAM disk processing can be increased dramatically. This option is also useful if the default directory (the current directory, or one named by the SEADOG environment variable) does not have enough free disk space. -D dir Place the final ARCmail files in the DOS directory 'dir'. This option is incompatible with versions below 1.0 of the ARCmail program created by System Enhancement Associates. -F file Takes area names from 'file' and only exports messages from those areas. -A ARC_cmd Create ARCmail files using the command 'ARC_cmd'. This MUST be the last option on the command line, and ARC_cmd consists of everything after the -A. The default ARC_cmd is 'ARC A'. Errorlevels returned: 0 - All processing terminated normally 1 - The maximum number of messages were output (the -M option) 2 - Severe error in processing Examples: Page 28 Conference Mail System Revision 3.3 December 12, 1987 MAINT: Function: Removes duplicate messages, and creates reply chain links in each Conference Mail message base. Format: Maint [-N] [-F file] [+areafile] area ... Options: -N Do not remove the duplicate messages, mark them as having been SENT. -F file Use the file 'file' as input for the list of areas to be processed. The file should have one area listed per line as in the following example: SYSOP TECH 23 C:\MSG\POINT +areafile Use the file 'areafile' as the AREAS.BBS file for this run. area The 'area' designates the conference to be processed. It may be a DOS path name, a Fido/Opus area number, or the actual name of the area as it appears in the AREAS.BBS file. Errorlevels returned: 0 - no messages deleted (or marked as having been sent) 1 - messages deleted (or marked as having been sent) 2 - severe error in processing Examples: To perform maintenance on message bases listed in the file Conf.Out Maint -F Conf.Out Use AREAS1.BBS and do not delete messages, just mark them as having been sent Maint -N +AREAS1.BBS Page 29 Conference Mail System Revision 3.3 December 12, 1987 RENUM: Function: Selectively delete and renumber Conference Mail message bases. Format: Renum [-E] [-Z] [-Q] [-S] [-O] [-B] [-M #] [-R area] [-D n area] [-K area] [-N n m area] Options: area The message base the Renum sub-function is to operate within. This may be specified as either a DOS directory name, or a Fido/Opus area number. -E Delete any messages encountered which have no content. This option should NEVER be used in the FidoNet mail area. -Z Delete any messages encountered which appear to have been "zapped", and do not have valid FidoNet message header information. This option should NEVER be used in the FidoNet mail area. -Q Operate in "quiet" mode. -S The system being used is a SEAdog system. -O The system being used is an Opus system. -B Do not attempt to backup the USER.BBS file (Fido/Opus systems). -M # The message base can contain up to '#' messages. The default is 2000. -R area Renumber the message area so that messages begin with message 1 and are numbered consecutively. Page 30 Conference Mail System Revision 3.3 December 12, 1987 -D n area Delete messages more than 'n' days old in the message area. The date of a message is taken from its arrival time on the system if that information is available (Opus 1.0 date format). If it is not available, then the message creation time is used instead. -K area Delete messages that have been received by the expected recipient. -N n m area Delete messages so that there are 'm' messages left after the first 'n' messages are saved. Errorlevels returned: 0 - all processing completed normally 1 - severe error in processing Examples: On a SEAdog system, save the first 5 messages in area 23, then delete messages until there are 100 left. After deleting, renumber area 23. Do all of this "quietly" Renum -S -Q -N 5 100 23 -R 23 Page 31 Conference Mail System Revision 3.3 December 12, 1987 HIMARK: Function: Generate a 'high water mark' for use by the Export sub-function to determine the messages already sent. Format: HiMark [+areafile] [-1] area ... Options: +areafile 'areafile' is the name of the file to use in place of the default of AREAS.BBS. -1 Set the "alternate" set of high water marks (see the Export description for more details). area The 'area' designates the conference to be processed. It may be a DOS path name, a Fido/Opus area number, or the actual name of the area as it appears in the AREAS.BBS file. Errorlevels Returned: 0 - all processing completed normally 1 - severe error in processing Examples: Set the highest message in C:\MSG\SYSOP as the high water mark. HiMark C:\MSG\SYSOP Page 32 Conference Mail System Revision 3.3 December 12, 1987 SETMARK Functions: "Move" the high water mark in a Conference Mail message base to any message number. Thus allowing the Export sub-function to begin processing at a different location. Format: SetMark [+areafile] [-1] <area msg_num> ... Options: +areafile 'areafile' is the name of the file to use in place of the default of AREAS.BBS. -1 Set the "alternate" set of high water marks (see the Export description for more details). area The 'area' designates the conference to be processed. It may be a DOS path name, a Fido/Opus area number, or the actual name of the area as it appears in the AREAS.BBS file. msg_num The message number to use for the high water mark. Errorlevels Returned: 0 - all processing completed normally 1 - severe error in processing Examples: Set 32 as the high water mark in C:\MSG\SYSOP SetMark C:\MSG\SYSOP 32 Set 32 as the high water mark in the TECH conference, and also set 32 as the high water mark in the POINT conference. SetMark TECH 32 POINT 32 Page 33 Conference Mail System Revision 3.3 December 12, 1987 CHNGBITS: Function: Changes the CRASH and/or HOLD bit settings on ARCmail file attach messages. Format: ChngBits [=infile] command ... Options: =infile Use the file named 'infile' as a list of 'commands' to execute. The file should have one 'command' per line. command A string with the following format: net/node[C][H] where net/node is the net/node number of the system involved, and C/H stand for the CRASH/HOLD bits on the file attach message. If the corresponding character (C or H) is present in the command, then the bit is set to 1 (thereby causing that option to take effect), otherwise the bit is reset to 0 (disabling that option). Refer to the FidoNet mailer manual for your system for more information on the use of the CRASH and HOLD bits. Errorlevels Returned: 0 - all processing completed normally 1 - severe error in processing Examples: Change the ARCmail style file attach message for 132/101 to a CRASH message. ChngBits 132/101C Page 34 Conference Mail System Revision 3.3 December 12, 1987 BATCH FILE EXAMPLES The following examples illustrate several possible operating modes for the Conference Mail System. Each example is preceded by a short paragraph explaining the system configuration and the desired results. The corresponding section of the batch file used to obtain those results is then shown: 1. Importing all messages including ARCmail messages into the Conference Mail message bases using the new Opus 1.0 compatible date format. Conferences having messages imported then have maintenance performed on them. This is a typical installation in the FidoNet network. ConfMail Import -N -F ConfMail.out -A IF ERRORLEVEL 2 GOTO SEVERE IF ERRORLEVEL 1 GOTO DO_MAINT GOTO END_IMPORT :DO_MAINT ConfMail Maint -F ConfMail.Out IF ERRORLEVEL 2 GOTO SEVERE GOTO END_IMPORT :SEVERE ECHO Severe Error in Import or Maint :END_IMPORT 2. A "secure" version of the above example (see the section entitled "Advanced Features" for a discussion of a secure system). ConfMail Import -M -S -N -F ConfMail.out -A IF ERRORLEVEL 2 GOTO SEVERE IF ERRORLEVEL 1 GOTO DO_MAINT GOTO END_IMPORT :DO_MAINT ConfMail Maint -F ConfMail.Out IF ERRORLEVEL 2 GOTO SEVERE GOTO END_IMPORT :SEVERE ECHO Severe Error in Import or Maint :END_IMPORT 3. Exporting messages from all Conference Mail message bases into ARCmail files. When exporting messages send private replies via FidoNet mail. This is a typical installation in the FidoNet network. ConfMail Export -R -A IF ERRORLEVEL 2 GOTO SEVERE GOTO END_EXPORT :SEVERE ECHO Severe Error in Export :END_EXPORT Page 35 Conference Mail System Revision 3.3 December 12, 1987 4. Using AREAS1.BBS for those systems receiving ARCmail, and AREAS2.BBS for those systems not receiving ARCmail, export messages from all Conference Mail message bases. For those systems not receiving ARCmail, send out a maximum of 200 messages during this run. Send private replies via FidoNet mail. REM first handle the nodes that can receive ARCmail ConfMail Export AREAS1.BBS -0 -R -A IF ERRORLEVEL 2 GOTO SEVERE REM now handle those nodes that cannot receive ARCmail ConfMail Export AREAS2.BBS -1 -R -M 200 IF ERRORLEVEL 2 GOTO SEVERE GOTO END_EXPORT :SEVERE ECHO Severe Error in Export :END_EXPORT 5. Use a small RAM disk for holding the ARCmail packet files created during exporting. Since the RAM disk is small, only export 100 messages at a time, but continue on until all messages have been processed. Also create 'tiny' seen-by lines and include no AKA addresses. :LOOP ConfMail Export -M 100 -S 0 -T -P E:\ -A IF ERRORLEVEL 2 GOTO SEVERE IF ERRORLEVEL 1 GOTO LOOP GOTO END_EXPORT :SEVERE ECHO Severe Error in Export :END_EXPORT 6. On an Opus 1.0 system export messages into the Opus outbound directory in .OUT file format for later processing by oMMM. Use 'tiny' seen-by lines, and send private replies via FidoNet mail. ConfMail Export -O C:\OPUS\OUTBOUND -T -R IF ERRORLEVEL 2 GOTO SEVERE GOTO END_EXPORT :SEVERE ECHO Severe Error in Export :END_EXPORT Page 36 Conference Mail System Revision 3.3 December 12, 1987 7. Delete messages in three message bases based upon the criteria: 150 messages should exist in each area after the first message (stores the high water mark) is saved. ConfMail Renum -N 1 150 C:\MSG\SYSOP ConfMail Renum -N 1 150 C:\MSG\TECH ConfMail Renum -N 1 150 C:\MSG\POINT 8. A "typical" FidoNet system: Export messages using the Opus 1.0 date format (this does not cause compatibility problems with any other FidoNet compatible software at the time of this writing). Do maintenance on any message base having messages imported. Export the new messages in ARCmail format. Delete messages in several areas based upon the criteria that 150 messages should remain after message number 1 has been saved, and renumber these message bases after the deletion of messages. ConfMail Import -N -F ConfMail.out -A IF ERRORLEVEL 2 GOTO SEVERE1 IF ERRORLEVEL 1 GOTO DO_MAINT GOTO END_IMPORT :DO_MAINT ConfMail Maint -F ConfMail.Out IF ERRORLEVEL 2 GOTO SEVERE1 GOTO END_IMPORT :SEVERE1 ECHO Severe Error in Import or Maint :END_IMPORT ConfMail Export -R -A IF ERRORLEVEL 2 GOTO SEVERE2 GOTO END_EXPORT :SEVERE2 ECHO Severe Error in Export :END_EXPORT ConfMail Renum -N 1 150 C:\MSG\SYSOP -R C:\MSG\SYSOP ConfMail Renum -N 1 150 C:\MSG\TECH -R C:\MSG\TECH ConfMail Renum -N 1 150 C:\MSG\POINT -R C:\MSG\POINT Page 37 Conference Mail System Revision 3.3 December 12, 1987 HOW TO UPGRADE FROM FASTSCAN v2.0 TO CONFMAIL v3.3 To upgrade from FastScan v2.0 to The Conference Mail System v3.3, the following steps should be followed: 1. Read this manual in its entirety. 2. Edit all batch files so the program names FastScan, FastToss, FastKDup, and Renum are preceded by the program name ConfMail. For example: FastScan -A becomes ConfMail FastScan -A The older program names are still accepted as sub-function names under ConfMail. The following are the allowable substitutions: FastScan for Export FastToss for Import FastKDup for Maint These older names (FastScan, FastToss, FastkDup) may not be supported beyond version 3.3 of the Conference Mail System. 3. Run the program FIXHW giving it the name of your AREAS.BBS file. This program changes the system "high water marks" to the new format used by the Conference Mail System. Run it once for each AREAS.BBS file you use for exporting messages. Example: FIXHW AREAS.BBS FIXHW AREAS1.BBS FIXHW AREAS2.BBS 4. Change batch file commands to reflect any new features you wish to utilize on your system. 5. Backup copies of FastScan, FastToss, FastKDup, HiMark, SetMark, and Renum, then remove the originals from the DOS PATH. 6. Run the new system to be sure everything functions properly. If all goes well, at this point you will have upgraded to being a user of the Conference Mail System version 3.3. Page 38 Conference Mail System Revision 3.3 December 12, 1987 NEW FEATURES PRESENT IN CONFMAIL v3.3 As you have seen by now, there are many significant changes between FastScan/FastToss/FastKDup v2.0 and ConfMail v3.3. The most important of these will be (numbers beyond 14 are new additions in ConfMail v3.1 over ConfMail v3.0, numbers beyond 19 are new in ConfMail v3.2 or v3.3): 1. All capabilities of the old series of programs, plus the capabilities of the Renum program have been combined into one program. This saves approximately 128K in disk space. 2. The Exporting of messages has been dramatically increased. Testing has shown the increase to be on the order of 25-75% over ConfMail v3.0, and another 25-75% beyond that over FastScan v2.0 (depending upon the configuration of the system involved). 3. Optional support has been added for systems supporting "points." This is an additional price upgrade, and if you are interested, please contact Spark Software for pricing information. 4. The ability to run a "secure" system has been added. When the Conference Mail System is used in full security mode, it is very difficult for any unauthorized individuals to enter Conference Mail messages without receiving prior authorization from the sysop. See the section entitled "Advanced Features." 5. Support has been added for the new PATH: line in Conference Mail messages. See the section entitled "Advanced Features" for a discussion of this field and how it can be used. 6. The Maint sub-function has a new capability. In addition to its previous task of finding and deleting duplicate messages, it now also creates reply chain threads. Refer to your FidoNet mailer manual on the meaning of reply chains. 7. Support for using Opus 1.0 for doing outbound FidoNet mail has been added. 8. Support for "zone gateways" has been added. 9. Provisions have been made for exporting messages using two different AREAS.BBS files. 10. The Import sub-function is now capable of combining two separate conferences into a single area. 11. The Export sub-function is now capable of exporting messages from one message base with two or more different conference labels. 12. Private replies to Conference Mail messages can be detected and sent via private netmail rather than through Conference Mail. 13. Sysops can define a different "designer" origin line for each conference. Page 39 Conference Mail System Revision 3.3 December 12, 1987 14. Better error-checking for disk full conditions has been implemented. 15. A BAD_MSGS area where messages that are "bad" are placed by the Export sub-function. 16. The ROUTETHRU area for allowing routed echomail to pass thru a node. 17. Packets are now tossed when found in the current directory, and also any packets that are found in the network files directory. 18. Arguments can now be passed to the "command file" used in the form: ConfMail FILE xxx.cmd. 19. Duplicates are deleted or placed in the BAD_MSGS directory when they are imported, rather than when Maint is run. A database of the last 1000 messages in each area is stored in each message directory, and is updated whenever new messages are imported. This file takes up 16K for each area (about the size of 8 average messages). 20. Export can now take the file created by Import as input. This allows only certain message areas to be Exported. 21. There is a maximum of 200 message areas possible (the old limit was 100). 22. The -I parameter has been added to Export to enable ConfMail to do the ARCmailing automatically for Opus systems. Page 40 Conference Mail System Revision 3.3 December 12, 1987 IMPORTANT NOTICE: In the past, this section contained all kinds of words that basically meant "Don't rip me off, because it is illegal to do so, and if you use this product and it doesn't work, it isn't my fault". Well, that is still more or less true, but there is more now. Now, ConfMail is being distributed as "GuiltWare <no tm>". This is a "new" idea that I came up with. Basically, it means that if you use this product, then you do what you can to help promote good BBS'ing by other people. One aspect of good BBS'ing is to say "Thank you" in some way. For ConfMail, I would appreciate it if you would send $35 to your favorite local charity, in the name of "GuiltWare" and have the charity acknowledge receipt of your donation to the address given on the title page for Spark Software. If $35 is too much to ask, then at least send a thank you note from yourself - even a netmail message will do. If you cannot do at least that, then GuiltWare fits, because you should feel exceedingly guilty. Page 41